Kubernetes 自動化了生產中部署、擴展和更新應用程序所涉及的工作和重復的手動功能。由于 Kubernetes 部署控制器始終監控 Pod 和節點的健康狀況，它可以替換發生故障的 Pod 或繞過節點，替換這些 Pod 以確保關鍵應用程序的連續性。部署會自動啟動 pod 實例，并確保它們按照定義在集群中的所有節點上運行。更多的自動化轉化為更快的部署和更少的錯誤。

Kubernetes 提供了多種部署策略來處理廣泛的應用程序開發和部署需求。一旦您定義了應用程序的所需狀態，部署控制器就會以受控的變化率進行所需的更改。?

什么是 Kubernetes 重新創建部署？

重新創建策略會終止當前運行的 pod 實例并使用新版本“重新創建”它們。通常用于用戶活動不是問題的開發環境中。
重新創建完全刷新了 pod 和應用程序的狀態。因此，存在與舊部署的關閉和新部署實例的啟動相關的停機時間。

什么是 Kubernetes 滾動更新部署？

滾動更新策略允許從一個應用程序版本到新版本的有序、漸進式遷移。在此部署中，啟動了具有新版本的新 ReplicaSet，并且隨著新版本的副本的啟動，舊版本的副本被終止。最終，所有舊版本的 Pod 都被終止并被新版本取代。滾動更新可實現版本之間的有序轉換，但轉換可能需要一些時間。

什么是 Kubernetes 藍/綠部署？

一旦新版本在生產中進行測試，藍/綠策略提供了從舊應用程序版本到新應用程序版本的快速過渡。在這里，新的“綠色”版本與現有的“藍色”版本一起部署。當確信“綠色”版本按設計工作時，版本標簽將在執行負載平衡的 Kubernetes 服務對象的選擇器字段中替換。這會立即將流量切換到新版本。盡管這提供了避免版本控制問題的快速推出，但此策略需要兩倍的資源利用率，因為兩個版本都在運行直到切換。

什么是 Kubernetes 金絲雀部署？

在金絲雀部署中，較小的用戶組被路由到應用程序的新版本，該應用程序在較小的 pod 子集上運行以測試生產環境中的功能。一旦確信測試沒有錯誤，新版本的副本就會被放大，從而有條不紊地替換舊版本。Canary 部署非常適合在一小部分用戶上測試新功能，并且很容易回滾。因此，金絲雀部署可以很好地衡量新代碼將如何影響系統的整體運行。

部署是管理和擴展應用程序在集群上運行方式的最簡單方法，Kubernetes 的開放 API 簡化了與 CI/CD 管道的集成。?

一些常見的部署用例：

• Kubernetes 的一個流行用例是運行無狀態 Web 服務器，例如流行的開源 nginx。部署可以請求實例化固定數量的 pod 副本，Kubernetes 將在部署期間維護該數量的 pod。
• 需要像數據庫實例這樣的持久存儲的應用程序將使用 StatefulSet 類型部署并掛載持久卷以確保數據完整性和壽命。
• 隨著工作負載的增加，部署可以自動擴展集群中的副本數量，自動平衡副本之間的傳入請求，隨著需求的增加創建新的副本，并在需求下降時終止副本。

與大多數 Kubernetes 功能一樣，部署在 YAML（或 JSON）文件中描述，然后使用 kubectl apply 創建。

例如，一個名為“web-deployment”的 nginx 部署的 YAML 具有 4 個副本，如下所示：

api版本：應用程序/v1；

種類：部署

元數據：

名稱：網絡部署規范：

選擇器：

匹配標簽：

應用程序：nginx

復制品：4

模板：

元數據：

標簽：

應用程序：nginx

規格：

容器：

- 名稱：nginx

圖片：nginx：1.17.0

端口：- 容器端口：80

一旦定義了部署，它就會從 YAML 文件中創建：kubectl apply -f https://[location/web-deployment.yaml]

Kubernetes 中的 JSON 和 YAML 有什么區別？

YAML（YAML Ain't Markup Language）和 JSON（JavaScript Object Notation）都可以用來定義 Kubernetes 資源。許多用戶更喜歡 YAML 的可讀性。但是，由于 YAML 是 JSON 的超集，因此任何有效的 JSON 文件也是有效的 YAML 文件。

可以通過更改部署中的 Pod 模板規范來更新部署，這會自動導致更新推出。更改 Pod 模板將導致正在運行的 pod 停止接受請求，因此可以縮減它們，直到可以終止所有 pod。一旦它們被終止，更新的 pod 模板將用于創建新的 pod。

如果部署被認為不穩定或部署中有錯誤，則使用以下命令回滾到以前的版本：

Kubectl rollout undo [deployment_name]添加參數–to-revision=將回滾到該特定版本的部署